home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 23 / CU Amiga - Super CD-ROM 23 (June 1998).iso / CUCD / Sound / PreludeAMP / src / controldata.h < prev    next >
Encoding:
C/C++ Source or Header  |  1997-05-31  |  7.8 KB  |  223 lines
  1. #ifndef __CONTROLDATA_H
  2. #define __CONTROLDATA_H
  3.  
  4. #define MSG_CTRL         0
  5. #define MSG_BUFFER       1
  6. #define MSG_SONG         2
  7. #define MSG_QUIT         3
  8. #define MSG_NEXT         4
  9. #define MSG_QUERY        5
  10. #define MSG_RESPONSE     6
  11. #define MSG_BUFAHEAD     7
  12. #define MSG_FRAMES       8
  13. #define MSG_POSITION     9
  14. #define MSG_SEEK         10
  15. #define MSG_PRIORITY     11
  16. #define MSG_RELEASE      12
  17. #define MSG_AUDIOFAILURE 13
  18. #define MSG_INFO         14
  19.  
  20. /* MSG_PRIORITY */
  21. #define PRIORITY_NORMAL   1
  22. #define PRIORITY_REALTIME 2
  23. #define PRIORITY_NICE     3
  24.  
  25. /* MSG_CTRL */
  26. #define PLAY_STOP     0
  27. #define PLAY_PAUSE    1
  28. #define FORWARD_BEGIN 2
  29. #define FORWARD_STEP  3
  30. #define FORWARD_END   4
  31. #define REWIND_BEGIN  5
  32. #define REWIND_STEP   6
  33. #define REWIND_END    7
  34.  
  35. /* MSG_QUERY */
  36. #define QUERY_PLAYING 1
  37. #define QUERY_PAUSED  2
  38.  
  39. /* MSG_RESPONSE */
  40. #define FAILURE       0
  41. #define SUCCESS       1
  42.  
  43. struct m_cmsghdr
  44. {
  45.       unsigned int  cmsg_len;
  46.       int  cmsg_level;   
  47.       int  cmsg_type;    
  48.       int  fd;
  49. };
  50.  
  51. typedef struct __controlmsg
  52. {
  53.       int type;
  54.       int data;
  55. } TControlMsg, *PControlMsg;
  56.  
  57. /*
  58.  * The Jukebox assumes that the player reads its commands from stdin
  59.  * and writes its replies to stdout. The connection type setup by the
  60.  * jukebox and the player is of type socket.
  61.  * The jukebox knows nothing more about the player than the following
  62.  * messages. If they are properly implemented, any player should work.
  63.  *
  64.  * The receiving player should send the following messages when specific
  65.  * events occurs.
  66.  *
  67.  ************************************************************************
  68.  *
  69.  * MSG_NEXT
  70.  *   When the player is done playing a song, and the playing has not
  71.  *   been explicitly stopped by use of MSG_CTRL/PLAY_STOP, the player
  72.  *   need to send a MSG_NEXT to notify the Jukebox that it's done.
  73.  *
  74.  * MSG_INFO
  75.  *   When the player recieves and starts decoding a new song, it can
  76.  *   send a MSG_INFO to the Jukebox telling it about various data
  77.  *   regarding the song. The Information is sent by first sending
  78.  *   a MSG_INFO, directly followed by a AudioInfo struct.
  79.  *
  80.  ************************************************************************
  81.  *
  82.  * The receiving player should send the following messages at some interval
  83.  * to notify the Jukebox regarding its progress.
  84.  *
  85.  ************************************************************************
  86.  *
  87.  * MSG_POSITION
  88.  *  The data member of the message contains the file position, ie what
  89.  *  position is currently being played. This message updates the progress
  90.  *  bar.
  91.  *
  92.  * MSG_FRAMES
  93.  *  The number of Mpeg frames currently played. An Mpeg frame, as far as
  94.  *  I know is 4608 bytes. This message updates the clock.
  95.  * 
  96.  ************************************************************************
  97.  * 
  98.  * The receiving player can send the following messages to notify the
  99.  * player regarding some kind of error.
  100.  ************************************************************************
  101.  *
  102.  * MSG_AUDIOFAILURE
  103.  *   The player could not acquire the audiodevice.
  104.  *
  105.  * MSG_PRIORITY
  106.  *   If the Jukebox receives this message it will notify the user that
  107.  *   the player does not have the permissions required to use the priority
  108.  *   mode the user wanted.
  109.  *
  110.  ************************************************************************
  111.  *
  112.  * The receiving process has to be able to handle the following messages:
  113.  ************************************************************************
  114.  * MSG_CTRL
  115.  *
  116.  *   FORWARD_BEGIN
  117.  *   FORWARD_STEP
  118.  *   FORWARD_END
  119.  *     The reason there are three messages is because you might need to lock
  120.  *     the decoding/playing thread while jumping forward in the song.
  121.  *     Once the player has fulfilled one request, it responds with a 
  122.  *     MSG_RESPONSE, with data set to FORWARD_BEGIN, FORWARD_STEP, 
  123.  *     FORWARD_END. The reason for this is that the jukebox will not send
  124.  *     a new FORWARD_STEP or FORWARD_END request until it is certain the
  125.  *     previous has been served.
  126.  *     If you do not wish to implement forward, just send a MSG_RESPONSE
  127.  *     back immediately upon receiving a forward request.
  128.  *
  129.  *   REWIND_BEGIN
  130.  *   REWIND_STEP
  131.  *   REWIND_END
  132.  *     The same setup as with forward, and the response is MSG_RESPONSE with
  133.  *     data set to REWIND_BEGIN, REWIND_STEP, REWIND_END.
  134.  *
  135.  *   PLAY_STOP
  136.  *     This message is sent when the jukebox want the player to stop playing.
  137.  *     The player will not reply to this message in any way, and will neither
  138.  *     send a MSG_NEXT.
  139.  *
  140.  *   PLAY_PAUSE
  141.  *     This message is sent to either release a paused player, or to pause
  142.  *     the player. No reply is expected.
  143.  *
  144.  ************************************************************************
  145.  * 
  146.  * MSG_QUIT
  147.  *   This message is sent by the Jukebox when the jukebox want the player
  148.  *   to die. No reply is expected. The Jukebox will capture the SIGCHLD if
  149.  *   its around to receive it.
  150.  *
  151.  ************************************************************************
  152.  *
  153.  * MSG_QUERY
  154.  *   QUERY_PLAYING
  155.  *     This message is sent by the Jukebox when it needs to know if the
  156.  *     player is currently playing or not. It will expect a reply in the
  157.  *     form of MSG_RESPONSE, with data set to TRUE or FALSE.
  158.  *
  159.  *   QUERY_PAUSED
  160.  *     This message is sent by the Jukebox when it needs to know if the
  161.  *     player is currently paused or not. It will expect a reply in the
  162.  *     form of MSG_RESPONSE, with data set to TRUE or FALSE.
  163.  *
  164.  ************************************************************************
  165.  *
  166.  * MSG_SONG
  167.  *   This is the most complicated message that the player needs to support.
  168.  *   It's an ordinary message, followed by a message sent by sendmsg with
  169.  *   a filedescriptor `in flight'. Once the MSG_SONG is recieved and read,
  170.  *   the player immediately need to call recvmsg to fetch the filedescriptor.
  171.  *   The recvmsg requries a buffer as an argument. You should have one iovec,
  172.  *   a char buffer of two bytes, and an iovec length of 2.
  173.  *   Basically, if you're confused, look in sajberplay how it extracts the
  174.  *   filedescriptor from the message.
  175.  *
  176.  ************************************************************************
  177.  *
  178.  * 
  179.  * The following are features that should be included.
  180.  ************************************************************************
  181.  *
  182.  * MSG_BUFFER
  183.  *   The data contains the number of frames that the Jukebox wants buffered
  184.  *   ahead.
  185.  *
  186.  * MSG_BUFAHEAD
  187.  *   The data contains the number of frames that the Jukebox wants decoded
  188.  *   before actual play starts. Be careful with the relationship between
  189.  *   frames buffered and bufahead, or you'll deadlock.
  190.  *
  191.  * MSG_SEEK
  192.  *   This message tells the player that the Jukebox wants playing to continue
  193.  *   at the file position specified by the data.
  194.  *   Any request that can't be served should just be silently ignored,
  195.  *   like a rewind requests on a stream or socket.
  196.  *
  197.  ************************************************************************
  198.  *
  199.  * The following are features that would be good if they are included.
  200.  * Most of them are rather easy to do.
  201.  ************************************************************************
  202.  *
  203.  * MSG_PRIORITY
  204.  *   PRIORITY_NORMAL
  205.  *     Tells the player that is should set its scheduling and static priorities
  206.  *     to SCHED_OTHER and 0.
  207.  *   PRIORITY_REALTIME
  208.  *     Tells the player that its allowed to enter realtime scheduling and
  209.  *     changing static priorities as it sees fit.
  210.  *   PRIORITY_NICE
  211.  *     Tells the player that it's to use SCHED_OTHER scheduling but may change
  212.  *     static priorities at will.
  213.  *   
  214.  * MSG_RELEASE
  215.  *   The data member of the message is either TRUE or FALSE. This message
  216.  *   tells the player if it should release the audiodevice on an explicit
  217.  *   MSG_STOP or when playing stops [The player might want to wait with
  218.  *   releasing the audio device until the Jukebox has had ample time 
  219.  *   anwering a MSG_NEXT].
  220.  */
  221.  
  222. #endif
  223.